Composite Applications are collections of multiple components and component types brought together for a business purpose. They allow integrations of different technologies on the glass so that end users get all the tools and functions in one application they need to get their jobs done. Composite applications also allow the easy reuse of coarse grained components by using loosely coupled components that talk between each other via property broker and WSDL. Composite Applications are part of many software packages such as Lotus Notes 8.0 (Lotus, Notes and related terms are trademarks of IBM Corp. in the United States and/or other countries).
In composite application definitions (CA XML) you define the links to components. NSF (e.g., Lotus Notes-based) component links have currently a link to certain design elements in a specific NSF. For example: Notes://serverName/replicaId/AllDocs?OpenView
The problem with these links is that they point to a specific server and a specific database. However developers usually implement a composite application and the components in a development environment first. After this has been completed and tested successfully, the composite application (e.g., one NSF) and the components (e.g., other NSFs) are deployed to other environments.
There are different ways to deploy NSFs to servers: 1. replicate, 2. copy per file system, 3. create copy of db, etc. In some of these cases the replica ids of the component NSFs change. In any case the server changes. Even though the server is only a hint and Notes looks for other servers automatically, the server attribute in the Notes URL should be the real server to which the application was deployed since Notes failover does not always work in complex networks. Even if it always worked it would take a lot of time to locate the right server first which would not be tolerable in terms of the user experience.
In view of the foregoing, there exists a need for an approach that solves at least one of the deficiencies in the related art.